IBIS Macromodel Task Group Meeting date: 19 October 2021 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis Jared James Google: Zhiping Yang Intel: Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao * Majid Ahadi Ming Yan * Radek Biernacki * Rui Yang Todd Bermensolo Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: * Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Majid Ahadi introduced himself to ATM. He had recently attended his first Open Forum meeting as well. He received his Ph.D. from Georgia tech in May of 2021. He joined Keysight and is working on developing their AMI model building tools in ADS. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the October 12th meeting. Randy moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: GDDR6X: Walter and Randy said they had no new updates. Walter summarized the current status. He said we had proposed solution from 2 different EDA companies that think they know how Tx GetWave functions could deal with the issues GDDR6X presents (see previous weeks' minutes for discussion of the issues). He said we expect to be able to evaluate various solutions in the future as more data from device manufacturers is made available for validation. Supporting PI modeling/simulation in IBIS: Randy reported that he is performing simulations on buffers to gather data that might be helpful to Chulsoon Hwang as he drafts a PSIJ BIRD. He said he is sanitizing the data and expects to have something to share in the coming weeks and send to Chulsoon. Walter commented that there are two broad categories of PI modeling. There is the total power the chip uses, and there is SSO. Both are related to power, but SSO is related to local power and crosstalk. When some people do PI, they are looking at the total power requirements of the chip. Walter said nothing IBIS has done traditionally deals with total power consumption of the chip. He said perhaps only 20 to 30% of that total is related to I/O device power. The total chip requirements are much larger than SSO related power draw, and the frequency dependency of the power is mostly related to core power. If we are considering SSO, then the IBIS power-aware models make sense. However, for full chip PI, IBIS is missing much larger parts. Randy said Chulsoon's PSIJ proposal is relative to the SSO and is more of an effect of PI on SI. He said Zhiping is working on other proposals to look at more global PI considerations. Walter said power spectral density is used to capture power load variations from the whole chip. We may want to propose keywords to handle the power spectral density, and IBIS needs to be careful to make sure we distinguish between the two PI categories. BIRD209 (originally BIRD204): Arpad asked about the BIRD's new Rx_Use_Clock_Input parameter. In the Usage Rules, he wondered whether we gave enough specifics about what portion of the .dll function(s) signatures are used. He asked if the tool should just copy the waveform output of the DQS GetWave to the clock_times input of the DQ GetWave (if the value of Rx_Use_Clock_Input for the DQ GetWave is "Wave"). Walter agreed this was the intent. He noted that the tool could conceivably pass the pointer around instead, but this could be dangerous. Arpad asked if we thought that more clarifying text was needed. Ambrish said he thought there was no need to change. Curtis agreed with Ambrish. Fangyi said this confusion might be more likely since we are overloading the clock_times vector, which was previously only an output from the model. Fangyi suggested you could think of this use of clock_times like a C union type. Walter said that the EDA vendors in attendance seemed to think the existing description is sufficient. He said the question will be whether other people writing model wrappers and tools find it clear. The group decided no action was needed at this time. GitHub Model Library repository proposal: Radek noted that Chulsoon and Zhiping had presented a demo of a potential GitHub site for storing IBIS model libraries. He asked whether ATM should invite them to present here. Arpad said he wasn't sure it was in our purview. Radek said the goal is modernizing distribution of libraries, but he wasn't entirely sure it was necessary. Randy said the Open Forum presentation had shown a demo and discussed possible access control levels (those who can download only, those who can upload, etc.). Arpad said he had asked if this might allow older models that the original authors had stopped supporting to be updated, for example, if an old AMI file had a Model Specific parameter that had since been approved as a Reserved Parameter. Walter said he thought models in the library were best used as references and examples of what had been done in the past. He said it would be risky to modify old models and not be using the latest approved models from your vendor. Ambrish said it would be problematic to have someone who doesn't own a model attempt to modify it. Since several attendees had missed the Open Forum meeting and were interested in seeing Chulsoon's demo, Arpad took an AR to invite him to present the concept to ATM. Automotive SERDES conference: Walter said that he had recently attended an automotive SERDES conference in Berlin. He noted that in the automotive industry many of the existing electronic devices are proprietary and done independently by different manufacturers. He said the auto industry is now making an effort to standardize many cables, sensors, etc., and they are now going to SERDES because of band- width requirements. He noted that one of their biggest bandwidth issues is being driven by the proliferation of 4K video monitors in cars. In addition, there are bandwidth requirements because of all the sensors for autonomous driving. He reported that they were discussing settling on standards for PAM2, PAM4, PAM8, and PAM16. Arpad asked if Walter expected that there would be SERDES developments that are entirely new to those of us in the field. Walter said he thought the automotive industry would be working in the same general realm as we were when AMI modeling started. He said they were typically 6 to 10 Gbps in NRZ. He said they will certainly go to PAM4, and they say they want PAM8 and PAM16. He said they might be able to do it since they are only talking about 2G symbols/sec. He noted that they plan to use FEC on some channels. He said another interesting point is that many of their channels are highly asymmetric. Most channels we've typically considered in IBIS-AMI are symmetric in that they have the same band- width in both directions. In automotive applications many devices, for example, a video camera sensor, only need high bandwidth in one direction. He said in some cases they're looking at up to 14m long coax cables or 10m long dual- shielded differential cables. Jitter Decomposition: Walter raised a new topic. He said we often talk about random, deterministic, sinusoidal, etc., jitter terms. We talk about some mathematical descriptions that don't exist in reality. In the real world, a scope measures the waveform, creates an eye, and then does jitter decomposition. It looks at the histogram of the eye crossings at zero volts. Sometimes it has two bumps, or one narrow or wide bump, etc. Typically, the scope tries to decompose that into deterministic and unbounded jitter (Dj and Rj). He said he suspects that every manufacturer has their own way of doing decomposition. Walter said standards are often vague or have differing rules on how jitter decomposition is done. Walter said there might be an opportunity for IBIS to come up with terminology and algorithms for decomposition. People could contribute various methods for doing the decomposition, and these could be defined and published by IBIS so companies can refer to a standard when they implement decomposition. He wondered if some test equipment organization had already done this, and he said there might be an opportunity for IBIS if they hadn't. Arpad asked how much this would have to do with device modeling. Radek said vendors want to mimic the behavior of their measured devices. They asked what the interest would be for AMI simulation. Walter said if someone is evaluating a channel, they want to know if it will pass a jitter compliance test: channel -> simulation -> eye diagram -> compliance test. Majid said that scopes are trying to decompose the jitter components from the measured signals. With AMI modeling, we tend to be adding jitter in to the simulation results, i.e., composing jitter as opposed to decomposing. Walter agreed partially. He said that even if you do an AMI simulation without introducing jitter explicitly, the ISI and other effects of the channel are already included in your results. So, simulation could also make use of decomposition. Fangyi noted that mathematically, jitter can't be separated into its components. He referred to a paper he had presented at DesignCon in 2014. Walter agreed. Fangyi said that because of this fact any jitter decomposition depends on assumptions. These are more like a definition than a mathematical description. He said any method that speeds up the jitter decomposition process might vary from algorithm to algorithm (because they are based on different assumptions). That intellectual property is properly kept proprietary to the vendor. Walter agreed that every vendor may have a proprietary implementation. Fangyi said standards sometimes have their own definition of jitter. Walter said sometimes they don't define it well enough. Fangyi agreed. Arpad said we could continue the discussion next week. - Walter: Motion to adjourn. - Bob: Second. - Arpad: Thank you all for joining. AR: Arpad to invite Chulsoon to present his GitHub model library proposal to ATM. ------------- Next meeting: 26 October 2021 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives